While I find the idea interesting, several of the questions can t be correctly answered because the proposed choices are not realistic or too limited. On the question of the usage of money, I believe we should spend money to fund important projects but I don t want to fund people having important positions in Debian and doing important work . What should I reply? (Granted, there s the other item but that doesn t help getting a clear picture of the answers) On the question Do you prefer time based releases instead of the it s ready when it s ready releases? , it is putting two concepts in opposition when the release managers recently proposed a third way that combines both: time based freezes and release when it s ready . This is what I want and I can t adequately express it either in the current poll. Partagez cet article / Share This

I have prepared a poll for users of the Debian operating system at http://tinyurl.com/3y33ska. We had the idea for the poll during the preparation of the MiniDebConf that is currently taking place in Berlin. Please spread the link and fill out the form yourself. Visitors of the MiniDebConf have the option to fill out the form on paper.

That is my second day at the UDS in Brussels. I have attended some sessions about server and cloud yesterday. The Ubuntu people are better organized than the Debian people during Debconf. They are collaboratively preparing the sessions in Launchpad and make notes with the Gobby editor during the session. Gobby allows group editing via Internet. The release date helps to keep the focus on stuff that can be done within the time frame and helps to concentrate on getting results.

It will probably be only 5 months for Maverick because Mark asked for a release on 10.10.10 which is an interesting date after removing the dots and converting it to a decimal number. I am comparing it to Debian: Toy Story 3 will be shown in cinemas soon and the Squeeze character is promoting the film. Will we use such a coincidence for more public attention and will will we release our Squeeze soon? I am afraid that it won't happen.

Our last session yesterday was about Tomcat packaging improvements. Debian and Ubuntu are using and maintaining identical packages of tomcat6 using the alioth infrastructure of the pkg-java team. Some of our plans are:

• fixing postinst to read configuration values from /etc/default/tomcat6
• add debconf support to allow modification of /etc/default/tomcat6
• document alternatives to authbind since authbind does not support IPv6
• document 2 ways to package web applications using tomcat6 or tomcat6-user
• transition from the old libservlet2.[34]-java packages to the current libservlet2.5-java package
  

Some days ago I wanted to create a page that displays your override bugs against the virtual package ftp.debian.org in a way that allows simple copy pasting the dak command from it. The functionality should be similar to the existing removals page. The result of my work can be seen at http://ftp-master.debian.org/~twerner/override.html. I could not find a HTML/CSS template that looks like an official Debian page - what a pity. That is why I have stripped down the existing removal page and tried to make it more appealing. Finding two colors that suit the background color of our title was another challenge. I hope you like it.

Please don't tell me that my page is using Javascript. It is 2010.

Most readers probably have installed Debian version 5.0 (Lenny) or an older version and are using shadow passwords with the md5 hash algorithm. This is not bad but not good enough. You can find out the details by looking at /etc/passwd and /etc/shadow (as root). The second column in these files should be a simple character x in /etc/passwd and a string like

$1$biMft/Pr$Lo3zPpiItdLZrzx8t/mTy0

in /etc/shadow. The number 1 between the 1st and 2nd $ sign means md5, the following string biMft/Pr is the salt and the last string Lo3zPpiItdLZrzx8t/mTy0 is the actual hash for the password ('testmd5' in this case). The salt is used to avoid attacks based on precomputed hash tables.

The package pam has switched to the stronger sha512 algorithm in version 1.1.0-2 on 31st august 2009. Look for a line like

password        [success=1 default=ignore]      pam_unix.so obscure sha512

in file /etc/pam.d/common-password if you have installed at least version 1.1.0-2. After changing the password I have the new password string

$6$qjc5gFgK$vaz/gLKMyDuhsVOU2oVIkDZrD0.reJM.2Ft3CMEoAsjN/lenvHC2ls6g/MY1ZaYaYBP3HHDOxel1dvTerl17q1

in /etc/shadow. The number 6 means sha512 and the hash

vaz/gLKMyDuhsVOU2oVIkDZrD0.reJM.2Ft3CMEoAsjNlenvHC2ls6g/MY1ZaYaYBP3HHDOxel1dvTerl17q1

is much longer than before.

The pam_unix module in combination with the sha algorithms allows specifying the number of rounds for hashing the password with the argument rounds=... which defaults to 5000. My current machine needs about 20 milliseconds to hash my password. That can be tested with the command

/usr/bin/time -f %U su testmd5 -c true

I have changed the number to 1 million

password        [success=1 default=ignore]      pam_unix.so obscure sha512 rounds=1000000

to make brute force attacks more difficult. After changing the password again the string is

$6$rounds=1000000$Va4plzLi$EtixueZQ1ZQlzQa7eHHsG6UcNvu.EnuCqM79kIyUe82eAZ.JNegn4SBY1RduYlACs0RWLFHD4d//PzQXMsCqk0

with the number of rounds embedded. The su command needs 1.79 seconds now which is an acceptable delay for the login process considering the improved security.

Don't forget to change the root password too if you have set one.

Since some days we keep packages of Architecture: all in the archive as long as they are needed. You can find some details about that in my former post:
dak dominate will dodadoda the Debian archive soon.

The package that could currently profit most from that change is rpm! But the package dependencies are actually not strong enough. The source package rpm builds some arch all packages like rpm-common and several arch any packages and some of them (rpm, librpm0) have an unversioned field
Depends: rpm-common.
This dependency can be improved to
Depends: rpm-common (= $ source:Version )
to avoid nasty bugs after upgrading.

I fear that we have more of such packages in Debian.

This blog post is about fixing the bug #246992: 'arch all package available before arch any dependancy'. What does that mean: we will keep multiple versions of arch all and source packages per suite as long as older arch 'any' package are still available because maybe newer versions haven't been built by the buildds yet. That means that packages from the unstable suite will always be installable in the future.

The old code in make_suite_file_list.py has been replaced by generate_filelist.py and dominate.py. The first one is generating the file lists for apt-ftparchive and the second one removes obsolete packages from the database. The code in make_suite_file_list.py has been written by people that are no longer members of the ftpteam. Its main control function has a nice name: do_da_do_da(). The new script dominate.py still ships with a small function doDaDoDa() as a reminiscence to our forefathers.

My code has been merged into dak and will be activated on ftp-master.debian.org soon. It can't re-add packages that have already been removed in the past but is will make the archive more friendly in the future. Unfortunately it will leave more cruft in the archive that cannot be cleaned fully automatically. We will need your help to find such corner cases. Please report any errors in the archive as a bug report against the virtual package 'ftp.debian.org'.

More information about the topic can be found in ftpteam's wiki.

Colophon This site is powered by Jekyll and based on styles and markup by Tom Preston Werner. Comments are run by Disqus and hosting is by Dreamhost. Before starting this site, I had an Advogato diary for writing about software. I also have a personal journal (mostly interesting to my friends and family).

I think this was my first contribution to the Debian operating system:

grace  (5.0.3-1) unstable; urgency=low

* added Replaces: xmgr, closes #35010, #42115, the only conflicting
  file is the grconvert binary which is identical in both packages
* changed editor to sensible-editor
* redebianized using dh_make and debhelper
* new upstream, closes: #41146, #27308, #28944, #29705, #38214
* NMU

-- Torsten Werner   Mon, 6 Sep 1999 22:19:04 +0200

That was 10 years ago. By the way the package is still in the distribution but orphaned now. Please note that our bug numbers had 5 digits only!

I don't want to count the packages that I am involved today but I am concentrating on Java related stuff. We got OpenJDK into Lenny and since DebConf9 it is our default JDK. Thanks to the recent work of Ludovic Claude we can use Maven for building official Debian packages. That will hopefully make packaging easier for many packages where upstream is using Maven as the build tool. I recommend joining the debian-java list if you are interested in those topics.

And I am a member of the FTP team today which is a great honour. It is quite
some extra work but we are now closer to the 1 week waiting time for NEW
processing (on average). Processing NEW is another place where I could see that
times are changing: this week I accepted a package (c) Microsoft Corporation
into Debian main what seemed to be impossible ten years ago.

This weekend, I was going to go to an acquaintance so that we could edit the material which we had filmed at the concert. Yes, we did use DVswitch, but due to me being somewhat late in proposing a video team, there was no team, and hence nobody switched anything. So instead we'll have to edit stuff now. Since I'd never done anything of the sort before, I guess it's fair to say that I'm not exactly the expert. As such, I installed samba, plugged the (LVM2/ext3 formatted) external hard disk containing the movie files to my laptop, and served them over a gigE link to his; the idea being that we could then do the editing on his system, using the software which he knew. After having copied those files (one 22G DV file, one 15G one, and a few much smaller ones), he loaded them into the editing software. Which promptly sat on its ass, making us wait, as it 'analyzed' the movie clip. This of course took ages. As said, I don't really know a lot about movie editing. However, in preparation to this, I had been playing with Cinelerra CV, and so I knew that this particular application does not require such an utterly useless delay. This I told Werner, who got interested. So we went over to Cinelerra's website, and had a look at the features list. That got him interested, and he suggested that it might be more interesting for me to install Linux and Cinelerra on his laptop, so that he could do the editing using that, rather than the Windows application that he wasn't entirely fond of anyway. So I did. A few hours later, everything was up and running, we had had lunch, and we were copying data from my external hard disk to his. As we were waiting on the data to be copied, I installed foobillard, and we had a bit of fun playing pool and snooker. Closing words, as we were wrapping up and he had a slightly more general look at the system: "sortof useful these days, isn't it?" Sure. I really believe that this kind of thing is the ideal way to do advocacy; rather than suggesting freedom for freedom's sake, one should suggest something people actually care about, and work from there. Of course, that doesn't always work.

following the traditional post.
I got an email today, telling me that I m a full Debian Developer now, I started my NM process on 2007-12-10 it took a bit more then a year, and now I m the first DD of El Salvador I have to thanks to all people that help me out, anibal, gregoa, dmn, mlt(Marcela), xerakko, twerner, benh and some more people that I don t remember.

The Debian Python Modules Team is discussing which DVCS to switch to from SVN. Ondrej Certik asked how to generate a list of commiters to the team s repository, so I looked at it and got this:
emilio@saturno:~/deb/python-modules$ svn log egrep "^r[0-9]+ cut -f2 -d sed s/-guest// sort uniq -c sort -n -r
865 piotr
609 morph
598 kov
532 bzed
388 pox
302 arnau
253 certik
216 shlomme
212 malex
175 hertzog
140 nslater
130 kobold
123 nijel
121 kitterma
106 bernat
99 kibi
87 varun
83 stratus
81 nobse
81 netzwurm
78 azatoth
76 mca
73 dottedmag
70 jluebbe
68 zack
68 cgalisteo
61 speijnik
61 odd_bloke
60 rganesan
55 kumanna
52 werner
50 haas
48 mejo
45 ucko
43 pabs
42 stew
42 luciano
41 mithrandi
40 wardi
36 gudjon
35 jandd
34 smcv
34 brettp
32 jenner
31 davidvilla
31 aurel32
30 rousseau
30 mtaylor
28 thomasbl
26 lool
25 gaspa
25 ffm
24 adn
22 jmalonzo
21 santiago
21 appaji
18 goedson
17 toadstool
17 sto
17 awen
16 mlizaur
16 akumar
15 nacho
14 smr
14 hanska
13 tviehmann
13 norsetto
13 mbaldessari
12 stone
12 sharky
11 rainct
11 fabrizio
10 lash
9 rodrigogc
9 pcc
9 miriam
9 madduck
9 ftlerror
8 pere
8 crschmidt
7 ncommander
7 myon
7 abuss
6 jwilk
6 bdrung
6 atehwa
5 kcoyner
5 catlee
5 andyp
4 vt
4 ross
4 osrevolution
4 lamby
4 baby
3 sez
3 joss
3 geole
2 rustybear
2 edmonds
2 astraw
2 ana
1 twerner
1 tincho
1 pochu
1 danderson
As it s likely that the Python Applications Packaging Team will switch too to the same DVCS at the same time, here are the numbers for its repo:

emilio@saturno:~/deb/python-apps$ svn log egrep "^r[0-9]+ cut -f2 -d sed s/-guest// sort uniq -c sort -n -r
401 nijel
288 piotr
235 gothicx
159 pochu
76 nslater
69 kumanna
68 rainct
66 gilir
63 certik
52 vdanjean
52 bzed
46 dottedmag
41 stani
39 varun
37 kitterma
36 morph
35 odd_bloke
29 pcc
29 gudjon
28 appaji
25 thomasbl
24 arnau
20 sc
20 andyp
18 jalet
15 gerardo
14 eike
14 ana
13 dfiloni
11 tklauser
10 ryanakca
10 nxvl
10 akumar
8 sez
8 baby
6 catlee
4 osrevolution
4 cody-somerville
2 mithrandi
2 cjsmo
1 nenolod
1 ffm
Here I m the 4th most committer And while I was on it, I thought I could do the same for the GNOME and GStreamer teams:
emilio@saturno:~/deb/pkg-gnome$ svn log egrep "^r[0-9]+ cut -f2 -d sed s/-guest// sort uniq -c sort -n -r
5357 lool
2701 joss
1633 slomo
1164 kov
825 seb128
622 jordi
621 jdassen
574 manphiz
335 sjoerd
298 mlang
296 netsnipe
291 grm
255 ross
236 ari
203 pochu
198 ondrej
190 he
180 kilian
176 alanbach
170 ftlerror
148 nobse
112 marco
87 jak
84 samm
78 rfrancoise
75 oysteigi
73 jsogo
65 svena
65 otavio
55 duck
54 jcurbo
53 zorglub
53 rtp
49 wasabi
49 giskard
42 tagoh
42 kartikm
40 gpastore
34 brad
32 robtaylor
31 xaiki
30 stratus
30 daf
26 johannes
24 sander-m
21 kk
19 bubulle
16 arnau
15 dodji
12 mbanck
11 ruoso
11 fpeters
11 dedu
11 christine
10 cpm
7 ember
7 drew
7 debotux
6 tico
6 emil
6 bradsmith
5 robster
5 carlosliu
4 rotty
4 diegoe
3 biebl
2 thibaut
2 ejad
1 naoliv
1 huats
1 gilir

emilio@saturno:~/deb/pkg-gstreamer$ svn log egrep "^r[0-9]+ cut -f2 -d sed s/-guest// sort uniq -c sort -n -r
891 lool
840 slomo
99 pnormand
69 sjoerd
27 seb128
21 manphiz
8 he
7 aquette
4 elmarco
1 fabian
Conclusions:
- Why do I have the full python-modules and pkg-gstreamer trees, if I have just one commit to DPMT, and don t even have commit access to the GStreamer team?
- If you don t want to seem like you have done less commits than you have actually done, don t change your alioth name when you become a DD (hint: pox-guest and piotr in python-modules are the same person)
- If the switch to a new VCS was based on a vote where you have one vote per commit, the top 3 commiters in pkg-gnome could win the vote if they chosed the same! For python-apps it s the 4 top commiters, and the 7 ones for python-modules. pkg-gstreamer is a bit special

It’s been so long since the film festival that I keep on forgetting half the good films I saw there when talking to people about it, so for the record here’s a brief list of my personal highlights:

• Encounters at the End of the World: Werner Hertzog goes to Antarctica, making a film more about the sort of people who end up spending their time there than about anything else. Though there are suicidal penguins.
• Mum and Dad: If you like this sort of thing the chances are you’ll think it’s brilliant. You may, however, still agree with the other people who don’t like this sort of thing and might describe it as being sick and wrong.
• Standard Operating Procedure: I blogged about this at the time; Errol Morris covers Abu Ghraib and does it very well.
• Just Another Love Story: I really enjoyed this when I saw it, though I do agree with most of the linked review. It’s a noirish thriller with three different time periods in the story being revealed in parallel. It looks gorgeous, it’s very well executed but I’m hesitant since I think I may feel differently when I see it again.
• Good Dick: In broad terms this is a very messed up take on a romantic comedy, more messed up than I believe it’s really intended to be (if you see it, think about what’s actually going on in the story). I enjoyed it for this and the contrast with the immediate tone but it’s not for everyone.

As far as the EIFF moving to June goes… I’m not convinced. I didn’t notice any dramatic improvement in the quality of the programme and while it did avoid the rain that Edinburgh suffered in August there’s nothing quite like the atmosphere you get during the main festival.

Does a GPG pass-phrase provide a real benefit to the majority of users? It seems that there will be the following categories of attack which result in stealing the secret-key data:

1. User-space compromise of account (EG exploiting a bug in a web browser or IRC client).
   
2. System compromise (EG compromising a local account and exploiting a kernel vulnerability to get root access).
   
3. Theft of the computer system while powered down when the system was configured to not use swap or to encrypt the swap space with a random key at boot time.


4. Theft of a computer system while running or that did not have encrypted swap.


5. Theft of unencrypted backup media.

Category 1 will permit an attacker to monitor user processes and intercept one that asks for a GPG pass-phrase as well as to copy the secret key. Category 2 will do the same but for all users on the system. Category 3 will give the potential for stealing the private key (if it’s not encrypted) but no direct potential for getting the pass-phrase. Category 4 has the potential for copying a pass-phrase from memory or swap. I am inclined to trust Werner Koch (and anyone else who submitted code to the GPG project) to have written code to correctly lock memory and scrub pass-phrase data and decrypted private key data from memory after use. But I really doubt the ability of most people who write code to interface with GPG to do the same. So every time that a GUI program prompts for a GPG pass-phrase I think that there is the potential for it to be stored in swap or to remain indefinitely in RAM. Therefore stealing a machine that does not have it’s swap-space encrypted with a random key (which is the most practical way of encrypting swap) or stealing a running machine (as mentioned in a previous post [1]) can potentially grant a hostile party access to the pass-phrase. So it seems to me that out of all the possible ways of getting access to a GPG private key, the only ones where a pass-phrase ones is going to really do some good are categories 3 and 5. While it’s good to protect against those situations, it seems to me that the greatest risk to a GPG key is from category 1, with category 2 following close behind. I previously wrote about the slow progress towards using SE Linux and GPG code changes to make it more difficult to steal the secret key [2] - something that I’ve been occasionally working on over the last 6 years. Now it seems to me that the same benefits can and should be made available to people who don’t use SE Linux. If a system directory such as /var/spool/gpg was mode 1770 then gpg could be setgid to group “gpg” so that it could create and access secret keys for users under /var/spool/gpg while the users in question could not directly access them. Then the sys-admin would be responsible for backing up GPG keys. Of course it would probably be ideal to have an option as to whether a new secret key would be created in the system spool or in the user home directory, and migrating the key from the user home directory to the system spool would be supported (but not migrating it back). This would mean that an attacker who compromised a local user account (maybe through a vulnerability in a web browser or MUA) would not be able to get the GPG secret key. They could probably get the pass-phrase by ptracing the MUA (or some other GUI process that calls GPG) but without the secret key itself that would not do as much good - of course once they had the pass-phrase and local access they could use the machine so sign and decrypt data which would still be a bad thing. But it would not have the same scope as stealing the secret key and the pass-phrase. I look forward to reading comments on this post.

• [1] http://etbe.coker.com.au/2008/02/17/hot-plug-and-how-to-defeat-it/


• [2] http://etbe.coker.com.au/2008/06/06/se-linux-support-gpg/

Share This

Software becomes more and more important in science as in other areas of life. Scientist have a tradition to publish their work very openly but that does often not include the source code of the software that was developed to carry out simulations which has some obvious problems such as:
- other scientists cannot check the software for errors,
- other scientists cannot fix the bugs and easily reproduce the results,
- other scientists cannot base their new research on already existing software and have to write it completely from scratch again and again,
- software package from different authors cannot be combined easily.

But things are getting better. One field of scientific research where we can see some improvement is machine learning - http://en.wikipedia.org/wiki/Machine_learning which is a broad subfield of artificial intelligence and concerned with the design and development of algorithms and techniques that allow computers to "learn". S ren Sonnenburg et.al. wrote a paper about "The Need for Open Source Software in Machine Learning" which is available at http://jmlr.csail.mit.edu/papers/v8/sonnenburg07a.html. They even created a portal with the goal to support a community creating a comprehensive open source machine learning environment at http://mloss.org.

An increasing number of software package are available in Debian like
- some simple-to-use utilities to apply compression techniques to the process of discovering and learning patterns: http://packages.debian.org/sid/complearn-gui
- a python package for convex optimization: http://packages.debian.org/sid/python-cvxopt
- a library for support vector machines: http://packages.debian.org/sid/libsvm2
- a machine-learning library: http://packages.debian.org/sid/libtorch3-dev
- an object-oriented programming language designed for researchers, experimenters, and engineers interested in large-scale numerical and graphic applications: http://packages.debian.org/sid/lush
- a large scale machine learning toolbox: http://packages.debian.org/sid/shogun-python-modular
- a data mining software in java: http://packages.debian.org/sid/weka

I'd like to know if you are using some of the packages or some other scientific software in Debian. Feel free to leave comment. Or maybe you are missing something in Debian?

If you are an author or user of some free software related to the topic of machine learning please consider registering it at http://mloss.org.

Some days ago I wrote down my experiences with packaging docbook-defguide. The main (remaining) issues I mentioned were the resources and the time the package needs to build. Even on an AMD X2 4600+ with 6GB of RAM it needs 7-8 hours. Today I met with Torsten Werner. He mentioned, that there are some move JVMs I could try. So I tested alternatives to GIJ this night. I found this short summary about free JVMs, which was some kind of interesting. I began with cacao, which seemed to be fast, but it was killed very early in the build process with an java.lang.OutOfMemory error. Even playing around with the -Xms and -Xmx switches in buildtools/saxon.sh did not help. So I dropped cacao from the list. Seems both cacao and kaffe create similar problems here and are not suitable for building the package. Second alternative I tried was sablevm. It directly throw out some warnings or errors so I directly dropped it too. Next JVM was jamvm. But it was as slow as GIJ. So I dropped it from the list of alternatives too. Then I found an interesting statement in the article I linked somewhere above. The author said, that his perfomance test time with GCJ/GIJ reduced from 433 to 9 seconds, when he compiled his application into a native executable. So I took a fast look through the docbook-defguide build dependencies and found, that Debian already provides a natively compiled Xerces package libxerces2-java-gcj. But there were no packages for libsaxon-java, libxml-commons-resolver1.1-java and docbook-xsl-saxon. So short and dirty: I downloaded the source for these packages, added the necessary stuff to get natively compiled packages too, built and installed them. Fortunately packages with native code already exist (JAXP 1.3 and Xerces) for their dependencies. And what should I say: Now building the TDG needs less then 512MB RAM and it builds in around an hour … even on my system. I will ask the Debian Java maintainers to add -gcj packages for Saxon and XML-Commons and fix my own docbook-xsl-saxon package. This will hopefully help maintaining docbook-defguide.

Congratulations to Werner Koch & Co: GnuPG, one of the most widely used pieces of crypto software, has just turned 10. If you like good infotainment, the birthday announcement reviews the last 10 years with facts and also some fun trivia.

IcedTea is the 100% free variant of Sun's OpenJDK. I have ported the existing Ubuntu package 'icedtea-java7' to Debian. My inofficial package is currently available at http://people.debian.org/~twerner/ for the architectures amd64 and i386. I do not plan to upload it to Debian.

* Sometime back, I came to know this little cool tool for previewing and comparing fonts. Did RFP–>ITP and then I came to know that it has one file gnome-specimen-about.svg under cc-by-sa license (Thanks to Torsten Werner for pointing out!). What to do?? I searched over packages and found that atleast one package is under similar license. So, I went ahead and submitted package (Was it brave step?). It took long time in NEW (due to license issue), but finally it got place. I contacted author (Wouter Bolsterlee) and told about this. A nice discussion followed. Tried Inkscape, no luck. And finally, 0.3.1 is with-out that cc-by-sa license!! You can get upstream tarball here. /me (Debian package will hit soon!)